FIG. 1 shows a prior art message flow diagram. Sender 102 with an email address “from@snd.dom” sends a message to recipient server 104 with an email address “private@rcv.dom”. Sender 102 and recipient mail server 104 communicate using the Simple Mail Transfer Protocol (SMTP) as described in the internet engineering task force (IETF) standard RFC821, which may include headers as described in IETF RFC2822. The communications shown in the figures may be carried out using any transport protocol, including Transmission Control Protocol of the Internet Protocol (TCP/IP), where TCP/IP has the property of retransmission of missing packets to ensure that the communications channel is free of information loss. In this manner, missing and errored packets do not cause disruption of the SMTP protocol shown in FIG. 1, as they are handled by the underlying TCP protocol.
In the prior art of FIG. 1, a particular sender 102 such as mail transfer agent operates in a first domain “snd.dom” with a user “from”, whereby under SMTP the sender email is “from@snd.dom”. Similarly, recipient 104 has a username “private” on the domain “rcv.dom”, resulting in the recipient email “private@rcv.dom”. In one type of network, a domain name is either globally known, such as a registered domain name, which is propagated using a domain name service “DNS”, or is locally known within a network, such that for either private or public names, the domain name resolves to an IP address that is reachable to all systems on a network. Within each domain, the users in that domain are locally assigned unique usernames, such that email may be sent from any user “user1@domain1” to any other user “user2@domain2”. The Sender 102 and Recipient 104 may be mail transfer agents (MTA) using SMTP, or for the sender 102, may be a mail client using SMTP. Typically, an email client will use SMTP for sending an email, while email servers will use SMTP for sending and receiving email. The SMTP transfer starts with the transmission 106 of a HELO packet which identifies the sending domain as “snd.dom”. This packet is acknowledged 108 by the recipient 104 including the recipient domain name in the reply “250 rcv.dom”. The sender 102 then transmits SMTP “MAIL FROM: from@snd.com” in step 110 identifying the sender's email address, which is acknowledged by the recipient 112. The sender 102 next identifies the recipient of the email as “private1@rcv.dom” in step 114, which is acknowledged 116. The SMTP “DATA” instruction is sent 118 followed by actual message data 120, which is acknowledged by the recipient 122. The final sender transmission SMTP “QUIT” 124 is acknowledged in step 126.
The well known SMTP provides for simple and efficient transfer of email. A problem arises when a private email address becomes widely known and is used for unsolicited advertising, such as a user email address “private@rcv.dom” is sold or passed from one bulk email sender to another. Among the ways this can occur is when a user registers for a web service, such as a newsletter, or makes a purchase on the internet from a vendor, who then resells customer lists to other promoters, or uses the list for their own unrequested promotions. The user then receives increasing amounts of email wholly unrelated to the original transaction. Once an email address becomes “tainted” in this manner, the user must sort through unwanted email messages among the desired messages. There are many prior art solutions for reducing the amount of unwanted bulk email, many of which rely on content filtering and the like. Filtering an email results in the message being dropped or deleted so that it does not appear in the recipient's mailbox, or alternatively it may be forwarded to another program for further analysis such as to form metrics for mail filtering based on content, as described in the patent prior art section which follows.
One type of prior art filter relies on a combination of message content and sender parameters, including a sender “whitelist” which is always received and a sender “blacklist”, which is always rejected, such as described in U.S. Pat. No. 6,421,709. U.S. Pat. No. 6,112,227 uses whitelists and blacklists, and additionally requests a source for an email register if they are not in a database, after which registration they are added to a whitelist, after the original email is forwarded to the recipient. U.S. Pat. Nos. 6,772,196 and 6,718,367 describes a system for examination of the content of the message to classify as a message to be filtered and dropped. U.S. Pat. No. 7,231,428 describes a similar system for management of email aliases that are pre-registered, whereby a message from a sender to an alias is forwarded to a plurality of recipients associated with that alias.
One type of filter relies on a “sender-receiver pair” whereby a sender and a receiver have address mappings, such as described in U.S. Pat. No. 6,643,687 by Dickie et al.